1. Field of the Invention
The invention relates to web applications. Specifically, the invention relates to apparatus, systems, and methods for automatically generating a web interface for an MFS-based IMS application.
2. Description of the Related Art
Computer and information technology continues to progress and provide tools that allow software applications to interact more easily than in the past. For example, web applications and web services have been introduced recently to allow a client application such as a ubiquitous web browser to communicate over a world wide network, such as the World Wide Web, with a server application programmed to provide a variety of services include banking, shopping, remote access, database access, and the like.
To control costs, web applications and web services interface with other computer and information technology which remains largely unchanged. For example, large corporations, governments, and other entities continue to use legacy applications such as software programs designed, written, and maintained for large, mission-critical computers, such as mainframes. These entities have invested large amounts of work and money into developing and maintaining the legacy applications. In addition, these applications have been tested and refined to operate very efficiently and with minimal errors.
Legacy applications continue to be used for managing a high percentage of the everyday transactions and data for these businesses. One example of legacy applications in wide-spread use are Message Format Service-based Information Management System applications (hereinafter MFS-based IMS applications). MFS is a component of the transaction management module for IMS. MFS translates transaction messages between various devices and the MFS-based IMS application which typically runs on a host such as a mainframe computer.
Converting or upgrading MFS-based IMS applications to the latest technologies and standards, such as web applications and web services, is often costly and/or impractical. Instead, components are built to translate messages between software applications executing modern standards and technologies and the MFS-based IMS applications.
For example, web interfaces may be constructed that convert between web messages utilizing Hyper Text Markup Language (HTML), eXtended Markup Language (XML), and/or Simple Object Access Protocol (SOAP) and proprietary transaction messages used by MFS-based IMS applications. In this manner, MFS-based IMS applications benefit from the new standards and technologies without making any changes to the MFS-based IMS applications themselves.
Proprietary transaction messages used by MFS-based IMS applications insulate the MFS-based IMS application from the differences in characteristics and layout among different device types and device features that cooperate to provide an interface for the MFS-based IMS application. The device features interfacing with MFS-based IMS applications may include hardware and software including different terminals, keyboards, mouse devices, monitors, light pens, touch screens, card readers, and the like. Instead of device specific code in each MFS-based IMS application, a common MFS control block known as a Message Input Description (MID) and Message Output Description (MOD) is defined for the different device types.
The MID and MOD define how the input or output messages are formatted and laid out for the specific input/output device. MFS supports a plurality of device types including the IBM 3270 terminal. MFS uses the MIDs/MODs to manage interface information such as field formats, field layouts, input devices, and the like. Because MFS manages the interface specific information, the MFS-based IMS application can focus on business logic that utilizes the inputs and outputs.
As mentioned above, a web interface allows non-MFS based IMS applications including web clients to interface with MFS-based IMS applications for implementing e-commerce requirements such as web enablement and/or web services. Non-MFS based IMS applications such as a browser send HTML/XML messages to the web interface, which alone or in conjunction with other components provides messages in the MID/MOD format to the MFS-based IMS application. However, MFS-based IMS applications typically support a large number of devices, which means that a corresponding large number of MIDs/MODs are defined. The web interface needs to know which MID and associated Device Input Formats (DIFs) and which MOD and associated Device Output Formats (DOFs) define an application interface for the associated MFS-based IMS application.
These MIDs and MODs specific to a MFS-based IMS application may be defined in an XMI (XML Metadata Interchange) file. The web interface uses the XMI files to convert an XML or HTML input message from a non-MFS based IMS application, such as a servlet, Java bean, SOAP, or browser client application, into the appropriate MFS input and output messages to communicate with the MFS-based IMS application.
Using XMI files, the web interface performs the run-time conversion of HTML/XML messages into suitable MID/DIF and MOD/DOF messages and vice versa. In addition, a web services description tool may use the XMI files to produce a description of the web service suitable for a web services directory such as a Uniform Description, Discovery, Integration (UDDI) directory. The web services description tool formats the web services description into a Web Services Description Language (WSDL) file.
Conventional tools exist for building web interfaces to MFS-based IMS applications. These tools produce servlets or Common Gateway Interface (CGI) applications which serve as a “bridge” between the client browser or application and a back-end legacy application such as MFS-based IMS application. Due to the complexity and potential number of MFS source files involved in generating a web interface for an MFS-based IMS application, these conventional tools involve a step-by-step Graphical User Interface (GUI) (i.e. a wizard). A user executes the GUI to create a web interface for a single MFS-based IMS application.
Unfortunately, conventional tools for generating a web interface require a user to manually step through each of the windows and enter basic information for generation of a web interface for a single MFS-based IMS application. The GUI wizard must be restarted to create a web interface for another MFS-based IMS application. Repetitively navigating each GUI window can be tedious for a user tasked with generating multiple web interfaces in a relatively short time period. In addition, because the client application (typically a browser) using the web interface remains substantially constant for each MFS-based IMS application, the data entered in each window of the GUI wizard is substantially the same. Tedious data entry of substantially the same information can cause the user to lose concentration and make mistakes.
GUI window based wizard tools for generating a web interface to an MFS-based IMS application may be helpful for a novice. However, a large number of administrators of MFS-based IMS applications have extended experience and intimate knowledge regarding the MID and associated MODs supported by the MFS-based IMS application. These administrators may manage hundreds of different MFS-based IMS applications, each having hundreds or thousands of associated MFS source files. The time required for such an administrator to use a conventional GUI wizard to generate the web interface for each of the MFS-based IMS applications becomes very burdensome.
In addition, certain GUI tools for generating a web interface simply convert the MFS source files into XMI files. Consequently, a second tool, often a GUI interface, must be run to generate a middleware application such as a servlet for interfacing with the MFS-based IMS application. Alternatively, the web interface GUI may be integrated within a larger GUI or Integrated Development Environment (IDE) that generates the servlet or other suitable middleware. Additional GUI tools for generating the servlet or middleware exacerbate the tedious nature of the GUI interface discussed above.
Finally, conventional GUI tools generate a web interface including a plurality of XMI files and/or middleware such as a servlet and store these in a directory. Next, the user must deploy these components to the webserver and or back-end computer system to make the web interface available to the client applications. Conventionally, this step may also include an additional GUI interface.
Accordingly, a need exists for an apparatus, system, and method for automatically generating a web interface for an MFS-base IMS application. In particular, the apparatus, system, and method should automate the generation of XMI files used for the web interface, servlets, and deployment of the generated components to the appropriate servers in response to a single input. The apparatus, system, and method should also automatically generate a web interface for a plurality of MFS-based IMS applications during a single execution session.